The Nilkins Engine is composed by components. Each of them will provide different functionalities that can be used together or not.
Each component has a position in the ecosystem. It could be represented by something like :
Level 0 | nkLog | nkExport | ||
---|---|---|---|---|
Level 1 | nkResources | nkTasks | nkMaths | nkMemory |
Level 2 | nkInputs | nkScripts | nkWinUi | nkImages |
Level 3 | nkGraphics | |||
Level 4 | nkAstraeus |
A component higher in the hierarchy can rely on one or more components from the lower levels. For instance, the nkTasks component uses the nkLog component. Or nkScripts uses nkExport, nkLog and nkResources.
For a more detailed description for each of them :
Component | Description | Dependencies |
---|---|---|
nkLog | Common logging interfaces among the components | - |
nkExport | Abstraction over exporting capabilities, such as Json... | - |
nkResources | Offers functionnalities to centralize path management | nkLog |
nkTasks | Helps with asynchronous work scheduling | nkLog |
nkMaths | Offers all needed mathematics functionnalities for the components | nkLog |
nkMemory | Offers memory handling capabilities, through pools, pagers... | nkLog |
nkInputs | Abstracts input devices and capabilities | nkLog, nkMaths |
nkScripts | Allows for scripting environment setup | nkLog, nkExport, nkResources |
nkWinUi | Offers ways to create system UIs | nkLog, nkExport, nkResources |
nkImages | Offers image formats encoding / decoding capabilities | nkMaths, nkMemory |
nkGraphics | Abstracts graphics API usage for graphical work | nkLog, nkExport, nkResources, nkTasks, nkWinUin, nkMemory |
nkAstraeus | Leverages all other components to offer higher level access to the engine | nkLog, nkGraphics, nkScripts |
The engine uses some third-party code :
The binaries packed into the archive come from the release configuration. While the engine is designed to be usable by any project configuration (debug, release...), some safeties can be disabled to optimize further the client build.
To avoid the compilers taking shortcuts and ignoring exported destructors for virtual classes designed as final, some classes are safe-guarded. Such classes are declared as final using the NK_FINAL keyword. By default, the keyword will hide that a class is final to the client compiler, to avoid any issue.
However, by defining the NK_ALLOW_DEVIRTUALIZATION preprocessor flag in the project settings, it is possible to disable this behaviour to have the classes properly seen as final. This will make the compiler properly take the shortcuts it wants to take.
This flag can generally be activated in any release configuration when using the engine. However, if any crash starts to happen when destructing an object coming from the engine, it means that this flag should not be activated.